Many large businesses rely on enterprise resource planning computing architectures and systems to electronically manage and coordinate business resources, information, and functions. In large organizations these computing architectures may be made up of hundreds of systems, distributed across various entities making up the organization. For example, a global business may rely on location-specific logistics systems to process orders in different localities, division specific supply chain management systems to manage supply chains across geographies, and business specific accounting systems to manage financial transactions at a business level.
Moreover, while each system in the enterprise resource planning computing architecture may have several modules or components active, not all of the modules or component in each system may used. For example, a global corporation's subsidiary in Canada may only use a logistics module on one of its enterprise resource planning systems, even though the system contains other several dozen other installed and operational modules, such as a finance and a human resources module. The same corporation's subsidiary in Germany may use a different logistics module on a second system and also use a finance module on a third system, even though the second and third systems may contain active logistics and finance modules, along with several dozen other modules.
While each of these systems may be administered by a local administrator, the local administrator may only have authority to manage users of the local system. For example, while the local Canadian administrator may manage users of the Canadian system, the Canadian administrator may not know about the German or French systems or users of German or French system other than those German or French users who require access to the components of the Canadian system.
As the size, number of entities, and number of enterprise resource planning systems of an organization increases, the complexity of the enterprise resource planning computing architecture also increases and becomes difficult to manage. Administrators, such as the Canadian system administrator, might not even be aware of the existence of many other enterprise resource planning systems and users of these other systems in the organization, and thus may not be able to assess security vulnerabilities posed by these other unknown systems and users.
For example, FIG. 1 shows an exemplary enterprise resource planning computing system including two enterprise resource planning (ERP) systems 80 and 90. Each of the systems contain at least three modules: finance module 81, logistics module 82, and human resources module 83 in system 80, and finance module 91, logistics module 92, and human resources module 93 in system 90. Each system 80 and 90 also contains its own access control and security settings. System 80, for example, may be part of a Canadian subsidiary's computing systems administered by Canadian administrators, while system 90 may be part of a German subsidiary's computing systems administered by administrators in Germany.
Administrators in Canada may only authorize user 10A to access logistics module 82, while administrators in Germany may authorize user 10B to access finances module 91. In this example, the organization does not use logistics module 92 in system 90 and human resources modules 83 and 93 in systems 80 and 90 respectively, as indicated by the “X” associated with the respective modules. Since user 10A has no need or authorization to access modules in system 90, while user 10B has no need or authorization to access modules in system 80, administrators in system 80 may not necessarily know of the functionality or even existence of system 90 or user 10B and administrators in system 90 may not necessarily know of the functionality or even existence of system 80 or user 10A.
Even though the users 10A and B only have limited access to a subset of modules each of their systems 80 and 90, respectively, the users 10A and B, may nonetheless attempt to connect to modules in another systems, as shown by the lines connecting user 10A to logistics module 92 and user 10B to human resources module 83. Although users 10A and B may fail in an attempt to connect to modules in systems that they do not have access to, in some instances, the users 10A and B, may be able to access unused modules, such as logistics module 92 and human resources modules 83 and 93.
Although the exemplary systems shown in FIG. 1 contains only three modules, in different instances each enterprise resource planning system may have several dozen or more modules installed and active, even through the organization may only use a handful of these active modules. If an organization has several dozen of these systems, then there could easy be several hundred unused modules in the organization.
Unauthorized access to these unused modules may present risks to organization, if, for example, the organization plans to use the modules in the future. The problem is further compounded when local system administrators may not even be aware of the functionality or existence of different enterprise resource planning systems in the organization to limit local system vulnerabilities.
Furthermore, when there are many different systems, it also becomes increasing complicated for the organization to keep track of which users and entities are using which modules and systems. The decentralized structure of enterprise resource planning systems within an organization, such as, for example administrators in Germany managing German systems, while Canadian administrators manage Canadian systems, makes it difficult to collect, organize, and manage information from each of these systems in a cohesive and intuitive form.
Thus, there is a need to prevent unknown entities within an organization from accessing unauthorized modules and systems. There is also a need to efficiently collect and manage usage data from a plurality of decentralized enterprise resource planning systems.